JBoss Community Archive (Read Only)

Infinispan 5.1

Design of data versioning in Infinispan

Overview

Infinispan will offer three forms of data versioning, including simple, partition aware and external. Each case is described in detail below.

Simple versioning

The purpose of simple versioning is to provide a reliable mechanism of write skew checks when using optimistic transactions, REPEATABLE_READ and a clustered cache. Write skew checks are performed at prepare-time to ensure a concurrent transaction hasn't modified an entry while it was read and potentially updated based on the value read.

When operating in LOCAL mode, write skew checks rely on Java object references to compare differences and this is adequate to provide a reliable write-skew check, however this technique is useless in a cluster and a more reliable form of versioning is necessary to provide reliable write skew checks.

Simple versioning is an implementation of the proposed EntryVersion interface, backed by a long that is incremented each time the entry is updated.

Partition-aware versioning

This versioning scheme makes use of vector clocks to provide a network partition resilient form of versioning.

Unlike simple versioning, which is maintained per entry, a vector clock's node counter is maintained per-node.

External versioning

This scheme is used to encapsulate an external source of data versioning within Infinispan, such as when using Infinispan with Hibernate which in turn gets it's data version information directly from a database.

In this scheme, a mechanism to pass in the version becomes necessary, and overloaded versions of put() and putForExternalRead() will be provided in AdvancedCache to take in an external data version. This is then stored on the InvocationContext and applied to the entry at commit time.

Write skew checks cannot and will not be performed in the case of external data versioning.

Tombstones

To deal with deletions of entries, tombstones will be maintained as null entries that have been deleted, so that version information of the deleted entry can be maintained and write skews can still be detected. However this is an expensive thing to do, and as such, is a configuration option, disabled by default. Further, tombstones will follow a strict lifespan and will be cleared from the system after a specific amount of time.

Configuration

By default versioning will be disabled. This will mean write skew checks when using transactions and REPEATABLE_READ as an isolation level will be unreliable when used in a cluster. Note that this doesn't affect single-node, LOCAL mode usage.

Via XML

<versioning enabled="false" type="SIMPLE|PARTITION_AWARE|EXTERNAL" useTombstones="false" tombstoneLifespan="60000"/>

Via the programmatic API

fluent().versioning().type(SIMPLE).useTombstones(true).tombstoneLifespan(1, TimeUnit.MINUTES);
JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-11 09:17:02 UTC, last content change 2012-01-13 16:21:25 UTC.